home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 658 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.3 KB
  1. Subject: Digest
  2. Date: Thu, 30 Jun 1994 22:38:31 +0200 (MDT)
  3. From: Annius.Groenink@cwi.nl (Annius Groenink)
  4. X-Face: "E3Hm]k]&:,OEP<{D2ixJf>-9[qOGLebNa0&cQyFL-a~)kTM3&&I"gFw=fJ]K%1IduGjOE`
  5.  ZGu]&~G]QNGa7i/L!+#Xng<|+}HKYHj~5?fTInUEUh0$I1gBI7jrA!&_|e/pR1[cX:^xgJTPsrjA_9
  6.  m8Zli[|.-u{]+c1(6C7mL*m`/_J\>.{4!:g
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11.  
  12. I've been away for awhile,  so this may be old news to you.
  13.  
  14. -----
  15.  
  16. Tim writes:
  17.  
  18. >Very nice.  'Add' is unambiguous but not too specific.
  19.  
  20. Michel Forget:
  21.  
  22. > I agree; (wow) Actually, "Append" is a much better word in this case.  It
  23. > clearly states what will happen, and has the same meaning as Append.  If
  24. > you really wanted an alternate name, "Attach Selection" would even be
  25. > better than "Add".  In context, "Add" is meaningless.
  26.  
  27. Append is better in context,  but not in all contexts.  How would you
  28. 'append' an image to an image?  This is precisely why I suggested to
  29. use 'add' instead.  That 'add' means 'append' in the context of text-based
  30. applications is obvious.
  31.  
  32. -----
  33.  
  34. Michel about SGI
  35.  
  36. > If you pay $200,000 for a computer, you can more or less expect these
  37. > things...  :)
  38.  
  39. Remove one nought and you can still buy two SGI machines.
  40.  
  41. -----
  42.  
  43. Mark H.
  44.  
  45. > And who is going to keep an undo buffer that will undo every key press/mouse 
  46. > action since a file was opened?
  47.  
  48. I believe Emacs does,  but agree that this is insane.  But then,  I'd
  49. agree on the insanity of every single piece of Emacs...
  50.  
  51. -----
  52.  
  53. Tim:
  54.  
  55. > I'm sure Edith is a FINE piece of work, although I haven't seen it.  I'm 
  56. > sure it has no (or no BIG) problem with Ctrl-A, but he had to put more 
  57. > work into the code to avoid the problems associated with Ctrl-A.
  58.  
  59. The fact that Edith has no safety problems with Control A  is totally
  60. independent of Control A itself---i.e. it is just a consequence of the
  61. general design strategy.  The choice to handle blocks independent of
  62. the cursor was of course not motivated by Control A problems but by the
  63. fact that the Macintosh paradigm ceases to make sense when blocks get
  64. discontinuous.  And the fact that Edith has no problems with Shift Backspace
  65. is the result from the fact that it turned out to be a wise decision
  66. to store the contents of a line for UNDO instead of only undoing the
  67. last character typed (Tempus does this too).
  68.  
  69. I haven't made ANY changes for the sake of making Control A safe.  My
  70. application (Edith) is safe,  and *therefore* so is the combination
  71. Control A.
  72.  
  73. This is the whole point of the discussion we have had so far.
  74.  
  75. (corollary:  only lazy programmers make unsafe applications.  Hence only
  76.  lazy programmers need to change Control A to avoid safety problems.  And
  77.  even then there will be other safety flaws in their software.)
  78.  
  79.  
  80. Ofir replies to Tim:
  81.  
  82. > >I'm sure Edith is a FINE piece of work, although I haven't seen it.  I'm
  83. > Then have a look at the demo.
  84.  
  85. By now,  Processor Direct magazine must have received their FREE FULL
  86. VERSION of the program...  Hopefully Tim will walk in one day and have
  87. a look at it.
  88.  
  89. -----
  90.  
  91. Aaaaaaaaaaarg.  My text editor (Jot on SGI for clarity) just crashed,
  92. losing my replies on 100KB of GEM-list material.
  93.  
  94. Anyway,  it was just a huge deal of Tim-bashing.
  95.  
  96. I'll try and summarize what I wrote...
  97.  
  98. -----
  99.  
  100. Leaving the right mouse button free is not necessary as MTOS and WINX
  101. allow using the left mouse button in background windows.
  102.  
  103. -----
  104.  
  105. About making the mouse take shapes on object types
  106.  
  107. > The technique of maintaining 2 bounding rectangles is feasible, but not
  108. > a trivial programming task.  It could provide other benefits though,
  109. > such as point-to-type, etc. 
  110.  
  111. Not easy,  but feasible is to calculate the smallest rectangle between
  112. objects in your tree the mouse is inside of.  I personally hate the
  113. Motif point-to-type idea  (but like it for active windows).
  114.  
  115. -----
  116.  
  117. Admittedly,  opaque (immediate) scrolling takes some time to get to
  118. work.  But designing your own GEM libs is very rewarding afterwards
  119. (good portability,  easy to create new applications).  No library will
  120. be as good as your own,  provided you're ready to put a few years into
  121. designing it.
  122.  
  123. -----
  124.  
  125.  
  126.  
  127.  
  128. -- 
  129. Annius V. Groenink | avg@cwi.nl              | Private/Edith/ZFC:
  130. CWI, Kruislaan 413 | A.V.Groenink@zfc.nl     | P.O. Box 12079
  131. 1098 SJ Amsterdam  | Room M233 ext. 4077     | NL 1100 AB Amsterdam 
  132. The Netherlands    | Phone:  +31 20 592 4077 | Phone: +31 20 695 9901
  133.